Doc previews:

• https://logstash_bk_16689.docs-preview.app.elstc.co/guide/en/logstash/master/configuration-file-structure.html#comments
• https://logstash_bk_16689.docs-preview.app.elstc.co/guide/en/logstash/master/environment-variables.html

Perhaps I am misunderstanding the issue but I thought that the problem here is that interpolation occurs regardless of whether the interpolation site is within a comment or not due to how the template is generated. This can lead to some somewhat confusing behavior where commented out sections still need values for interpolated values. The root of the issue is just the order of operations for interpolation in turning the information from template to instruction. SO instead of saying interpolation is not allowed instead should we describe the behavior and note that if you have interpolations anywhere in the string you need to ensure you have provided values?

Perhaps I am misunderstanding the issue but I thought that the problem here is that interpolation occurs regardless of whether the interpolation site is within a comment or not due to how the template is generated. This can lead to some somewhat confusing behavior where commented out sections still need values for interpolated values. The root of the issue is just the order of operations for interpolation in turning the information from template to instruction. SO instead of saying interpolation is not allowed instead should we describe the behavior and note that if you have interpolations anywhere in the string you need to ensure you have provided values?

I wonder what benefits does end user get if we explain the interpolation behavior.
From the end user experience, my practical approach here, user has mostly a running pipeline, later on comments env ${VAR} of the config.string. And once LS starts, the user faces an error and start searching context for using env ${VAR} in comments.